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UNITED STATES PATENT AND TRADEMARK OFFICE 



BEFORE THE BOARD OF PATENT APPEALS 
AND INTERFERENCES 



Ex parte BINDU RAMA RAO 



Appeal 2009-011663 
Application 10/782,083 
Technology Center 2400 



Before LANCE LEONARD BARRY, HOWARD B. BLANKENSHIP, and 
JOHN A. JEFFERY, Administrative Patent Judges. 

JEFFERY, Administrative Patent Judge. 

DECISION ON APPEAL 
Appellant appeals under 35 U.S.C. § 134(a) from the Examiner's 
rejection of claims 1-21 and 23-44. We have jurisdiction under 35 U.S.C. 
§ 6(b). We reverse. 



STATEMENT OF THE CASE 
Appellant's invention manages incoming access requests from 
multiple electronic devices during hardware or firmware updates. See 
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generally Spec, ff 0010, 0053. Claim 1 is illustrative with key disputed 

limitations emphasized: 

1. A method of gracefully managing incoming access 
requests during an update event from a plurality of electronic 
devices in a communication network, each of the incoming 
access requests comprising at least one update-related 
parameter, the method comprising: 

receiving each incoming access request at least 
temporarily; 

monitoring and evaluating the incoming access requests 
using the at least one update-related parameter, 

determining the availability of at least one device server 
to process the incoming access requests, based upon the at least 
one update-related parameter; 

immediately processing incoming access requests upon 
determining that the at least one device server is available; and 

communicating at least one message to electronic devices 
requesting access upon determining that the at least one device 
server is unavailable. 



The Examiner relies on the following as evidence of unpatentability: 

Boivie US 6,842,783 Bl Jan. 11,2005 

(filed Feb. 18, 2000) 

Peart US 6,952,714 B2 Oct. 4, 2005 

(filed Oct. 2, 2001) 

Vogl US 6,959,327 Bl Oct. 25, 2005 

(filed Aug. 29, 2000) 
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The Rejections 

1. The Examiner rejected claims 1, 3-6, 8-11, 19-21, 23-31, 35, 36, 38, 
and 40-43 under 35 U.S.C. § 103(a) as unpatentable over Boivie and 
Peart. Ans. 4-13. 1 

2. The Examiner rejected claims 13-18 under 35 U.S.C. § 103(a) as 
unpatentable over Boivie and Vogl. Ans. 14-16. 

3. The Examiner rejected claims 2, 7, 12, 32-34, 2 37, 39, and 44 under 
35 U.S.C. § 103(a) as unpatentable over Boivie, Peart, and Vogl. 
Ans. 16-20. 

The Obviousness Rejection Over Boivie and Peart 
Regarding independent claim 1, the Examiner finds that Boivie 
discloses a method of managing incoming access requests during an update 
event from plural electronic devices in a network with every recited feature 
except for (1) monitoring and evaluating the incoming access requests using 
at least one update-related parameter, and (2) determining the availability of 
at least one device server to process the requests based on the parameter, but 
cites Peart as teaching these features in concluding that the claim would 
have been obvious. Ans. 4-5, 21-26. 



1 Throughout this opinion, we refer to (1) the Appeal Brief filed December 
9, 2008; (2) the Examiner's Answer mailed February 25, 2009; and (3) the 
Reply Brief filed April 27, 2009. 

2 Although the Examiner indicates that claims 32-43 were rejected in the 
statement of the rejection, the body of the rejection indicates that the 
Examiner intended to reject claims 32-34 due to an apparent typographical 
error (i.e., transposing the "3" and "4" changing "34" to "43"). See Ans. 16- 
20. We therefore present the correct claim listing here for clarity. 
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Appellant argues that the cited prior art does not teach or suggest 
managing incoming access requests during an update event including 
monitoring and evaluating those requests using at least one update-related 
parameter as claimed. According to Appellant, not only does the cited prior 
art not teach or suggest an update event, let alone a parameter related to this 
event, but Peart' s execution request is sent from the server to the client 
which is a direction opposite from that claimed. App. Br. 7-9; Reply Br. 
2-3. Appellants add that the Examiner improperly combined the cited 
references since, among other things, (1) the stated motivation to combine 
the references is inapplicable given the direction of traffic in Peart noted 
above, and (2) the references are non-analogous. App. Br. 10-15; Reply Br. 
3. The issues before us, then, are as follows: 

ISSUES 

Under § 103, has the Examiner erred in rejecting claim 1 by finding 
that Boivie and Peart collectively would have taught or suggested managing 
incoming access requests during an update event from plural electronic 
devices in a network, each incoming access request comprising at least one 
update-related parameter, where the incoming access requests are monitored 
and evaluated using that parameter? 

FINDINGS OF FACT (FF) 
1 . Appellant notes that new versions (updates) of firmware and 
software for electronic devices (i.e., mobile electronic devices) are 
periodically made available to fix bugs, introduce and delete features, etc. 
Spec, f 0007. 
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2. According to Appellant's Specification: 

An update may comprise firmware or software updates that 
modify or change the version of a particular firmware or 
software installed in the device, for example, upgrading to a 
newer version, repairing a bug in the software, etc. An update 
may also add new services to the electronic device or delete 
services, as desired by a service provider, device manufacturer, 
or an end-user. 

Spec, f 0053. 

3. Boivie's system enforces communications-bandwidth-based 
service level agreements (SLAs) to customers hosted on a clustered web 
server. To this end, requests from clients 130 arrive at a Communications 
Bandwidth Manager (CBM) 1 10 via input link 241 and are queued in 
queuing system 360. Based in part on data monitored from outgoing data 
path 160 via the CBM's traffic estimator 340, the CBM's scheduler 350 (1) 
selects a request in the queuing system; (2) determines the server node to 
service the request; and (3) sends the selected request to the server node via 
link 280. Boivie, Title; Abstract; col. 1, 11. 10-14; col. 5, 1. 14 - col. 7, 1. 17; 
Figs. 1-3. 

4. Peart' s system automatically executes a program associated with a 
data file when the data file and executable program are located on different 
computing nodes (e.g., client and server). Peart, Abstract; col. 1, 11. 7-13. 

5. Peart' s web-based file- type association (FTA) embodiment enables 
transparent program execution on a server node by selecting graphical 
indicia presented on a client node that represent data files located on a web 
server. As shown in Figure 10A, after the client node receives a selection of 
a graphically-depicted data file, the client node provides this selection to the 
web server (steps 280-288). The client node then receives a request to 
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execute a first executable program (i.e., an execution request) (step 292), 
where the request includes parameters that (1) refer to the first and second 
executable programs, and (2) identify the selected data file on the web 
server. The client then executes the first program, and sends a request to 
execute the second program to the server (steps 296-300). Peart, col. 29, 1. 5 
- col. 30, 1. 5; col. 30, 11. 37-47; Fig. 10A. 

6. In one embodiment, the parameter identifying the selected data file 
is provided directly to the server node. Peart, col. 30, 11. 30-35. 

7. In one embodiment, the web server uses mappings which specify 
an association between a selected data file and executable programs. These 
mappings are received in groups or aggregated with other data such as 
software updates. The mappings can be updated either periodically or as 
needed. Peart, col. 31, 11. 45-67. 

8. Using received mapping information, the web server constructs 
and transmits an execution request to the client node, which the client node 
later executes. Peart, col. 32, 11. 1-4; Fig. 10B (step 324). 

9. Peart notes in connection with the client-based FTA embodiment 
that mappings and rules can be distributed over a live telecommunications 
link and in real-time while the client and server nodes are used. Peart, col. 
23, 11. 18-28. 

ANALYSIS 

Based on the record before us, we find error in the Examiner's 
obviousness rejection of independent claim 1 which calls for, in pertinent 
part, managing incoming access requests during an update event from plural 
electronic devices in a network, each incoming access request comprising at 
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least one update-related parameter, where the incoming access requests are 
monitored and evaluated using that parameter. We emphasize the term 
"during an update event" here, for we find the Examiner's reliance on Boivie 
for teaching managing incoming access requests during an update event 
(Ans. 4) problematic. 

In the Specification, Appellant describes updating in terms of 
providing new versions of firmware or software, or adding or deleting 
device services. FF 1-2. Although these types of updates are indicated in 
permissive terms (FF 2), they nonetheless inform our construction of the 
term "update event" which, when considered in light of the disclosure, 
means an event associated with (1) providing new versions of electronic 
device firmware or software, or (2) adding or deleting device services. 

Boivie, however, simply does not disclose an "update event" when 
construed in this context, let alone manage incoming access requests during 
such an event as claimed. Rather, Boivie enforces bandwidth-based SLAs 
by (1) queuing incoming requests, and (2) selecting particular queued 
requests and sending them to selected server nodes based on monitoring 
outgoing data. FF3. Boivie simply has nothing to do with updating. To the 
extent that the Examiner construes Boivie' s client-server data exchange or 
automatically selecting a particular request and corresponding server node as 
somehow constituting an "update" is problematic, for neither interpretation 
reasonably comports with an "update event" when construed in light of the 
specification as noted above. 

Nor does the Examiner's reliance on Peart cure this deficiency. That 
said, the Examiner is correct that Peart sends a parameter identifying a 
selected data file directly to the server node (Ans. 21; FF 6) which teaches 
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sending parameters from client to server. Appellant's arguments regarding 
Peart' s sending execution requests from the server to the client which is a 
direction opposite from that claimed (App. Br. 7-9; Reply Br. 2-3) — while 
correct {see FF 4) — simply do not address Peart' s alternative embodiment 
indicated by the Examiner noted above. 

Moreover, the Examiner's reliance on Peart' s mapping information 
(Ans. 22) has some merit, for Peart' s server uses mappings to construct and 
transmit execution requests. FF 7-8. Not only can these mappings be 
included in software updates, but the mappings themselves can also be 
updated. FF 7. In this regard, the Examiner's point (Ans. 22) that 
associated parameters would at least be related to these updates is well 
taken, for that is all the claim requires by reciting, somewhat broadly, an 
update- related parameter. 

But despite these update-related parameters in Peart, we still fail to 
see how incoming access requests containing these parameters would be 
managed during an update event as claimed — a crucial temporal 
requirement. Peart does, however, indicate in connection with a different 
embodiment that mappings can be distributed in real time and while the 
client and server nodes are used. FF 9. And as noted above, mappings are 
associated with update events. See FF 7. But we cannot say that this teaches 
or suggests managing incoming access requests during an update event as 
claimed, for the server receives mappings (and their associated updates) 
before receiving and processing requests from the client. See FF 5-8. 3 



3 Accord Peart, Fig. 9B (illustrating a server-side FTA embodiment where 
the mapping is received at the server before receiving stored data file 
selection from client). 
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Therefore, even if the references were combinable as the Examiner 
asserts, they still do not teach or suggest managing incoming access requests 
during an update event from plural electronic devices in a network, each 
incoming access request comprising at least one update-related 4 parameter, 
where the incoming access requests are monitored and evaluated using that 
parameter. Since this deficiency is dispositive of the issue before us, we 
need not address Appellant's arguments regarding the references' 
combinability. App. Br. 10-15; Reply Br. 3. 

We are therefore persuaded that the Examiner erred in rejecting (1) 
independent claim 1; (2) independent claims 19 and 42 which recite 
commensurate limitations; and (3) dependent claims 3-6, 8-11, 20, 21, 23- 
31, 35, 36, 38, 40, 41, and 43 for similar reasons. 

The Other Obviousness Rejections 
Since the Examiner has not shown that Vogl cures Boivie's 
deficiencies regarding managing incoming access requests during an update 
event noted previously, we likewise reverse the Examiner's rejection of (1) 
claims 13-18 over Boivie and Vogl (Ans. 14-16), and (2) claims 2, 7, 12, 32- 
34, 37, 39, and 44 over Boivie, Peart, and Vogl (Ans. 16-20) for similar 
reasons. 



4 Although independent claim 42 recites a selection-related parameter 
instead of an update-related parameter, our reversal nonetheless applies to 
claim 42 as well. 
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CONCLUSION 

The Examiner erred in rejecting claims 1-21 and 23-44 under § 103. 
ORDER 

The Examiner's decision rejecting claims 1-21 and 23-44 is reversed. 
REVERSED 



Pgc 
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